Method and apparatus for performing multicast in communications network

ABSTRACT

When one node has information to transmit to a group of nodes using a parameterized quality of service (PQoS) transmission, a broadcast flow is created rather than creating a multicast flow, which is not available. While the flow is created as a broadcast flow, if the flow is to be directed to less than all of the nodes on the network, then the flow will be considered a Multicast PQoS flow. The broadcast flow is created using a process that is known as a “PQoS Create Flow” transaction.

TECHNICAL FIELD

The disclosed method and apparatus relates to communications networks,and more specifically, to a method and apparatus for performingmulticast transmissions over a communications network.

DESCRIPTION OF THE RELATED ART

Some communications network protocols, such as the well-known Multimediaover Coax Alliance (MoCA) 1.x standard protocol, promulgated by the MoCA(Multimedia over Coax Alliance) industry standards body, implementmulticasting using broadcasting techniques, and provide no multicastgroup management. All of the multicast traffic is broadcast to all ofthe MoCA nodes on the MoCA network. Handling the multicast traffic inthis way creates two major problems: (1) when creating a PQoS(Parameterized Quality of Service) transmission for packets that aredirected to only some of the MoCA nodes (i.e., only some nodes want toreceive packets), a low-performing node (i.e., a node with limitedbuffer and/or limited host or bridge bandwidth) can prevent the creationof such a transmission, even when that low performing node need notreceive the transmission; and (2) a node may be flooded with non-PQoSmulticast traffic that it does not want (because it does not belong tothe multicast group and therefore the traffic is not intended for thatnode). This unwanted traffic can affect the reception of other moredesired traffic by taking up buffer and host (or bridge) bandwidth.

Accordingly, there is a need for a way to provide traffic only to thosenodes that desire to receive that traffic and relieve other nodes ofhaving to handle traffic that is not of interest.

SUMMARY OF DISCLOSED METHOD AND APPARATUS

Various embodiments of the disclosed method and apparatus for performingmulticasting are presented. In one embodiment, when one node hasinformation to transmit to a group of nodes using a parameterizedquality of service (PQoS) transmission (commonly referred to as a PQoSflow), a broadcast flow is created rather than creating a multicastflow, which is not available. It will be understood by those skilled inthe art that the term “flow” is used throughout this disclosure to referto a transmission of packets from a source node to one or moredestination nodes over a network, wherein the destination nodes are thesame for all of the packets of the flow.

While the flow is created as a broadcast flow, if the flow is to bedirected to less than all of the nodes on the network, then the flowwill be considered a Multicast PQoS flow. The broadcast flow is createdusing a process that is known as a “PQoS Create Flow” transaction. AFLOW_ID uniquely identifies each broadcast flow. The FLOW_ID iscontained in a “Request Layer-2 Management Entity (L2ME) Frame” from anetwork controller (NC). The FLOW_ID is generated by a “MoCA EntryNode”. The MoCA Entry Node initiates the PQoS Create Flow Transaction bysending the “Submit” message to the NC. Receiving nodes of the networkthat do not want to receive this flow respond to the reception of theflow by sending back over the network a “RESPONSE_CODE” value equal to“RESPONSE_CODE_UNINVOLVED”. The RESPONSE_CODE is transmitted by thereceiving node in a “Response L2ME Frame” of the PQoS Create Flowtransaction process. Application software informs the MoCA layer if thereceiving node will get involved in the flow. This application softwareruns in an application that is a part of a hierarchical layered softwareimplementation being implemented by the MoCA node and that runs abovethe MoCA layer. Each MoCA node will actually receive all MoCA broadcastpackets (including those that are part of a multicast flow). However,“egress filtering” will drop packets belonging to the multicast groupsto which the receiving node does not wish to belong. Those packets areidentified by a packet destination (e.g., “the PACKET_DA of the Ethernetframe”). For non-PQoS flows, a higher-layer application running withineach node will configure that node's MoCA receiver with multicast MediaAccess Control (MAC) destination addresses. If any of the flows receivedare directed to one of these MAC destination addresses, that flow willbe received, and all other flows will be dropped.

An alternative embodiment provides explicit multicast channel managementwithin a network communication protocol, such as MoCA. In thisembodiment, an Internet Group Management Protocol (IGMP) server withinthe MoCA network initiates a “MoCA Multicast Channel Management” processby invoking a “MoCA Entry” node. The MoCA Entry node is the MoCA nodethat starts the “MoCA Multicast Channel Management” process at MoCAlevel under the request of the IGMP server. The MoCA entry node may bethe same as, or different from, the MoCA Multicast Ingress node. TheMoCA Multicast Ingress node is the node from which the Multicast floworiginates. For each IP multicast, only one MoCA multicast channel willbe created.

The same L2ME protocol that is used for protocol management of the PQoStransactions is also used for Multicast Channel Management. The onlydifference is that in Multicast Channel Management for non-PQoSmulticasting, there is no TSpec involved (no need to calculate theamount of resources required and the time to complete the flow).Therefore, there are also no corresponding resources involved (sincethere is no guarantee of delivery within a particular amount of time orat a particular rate, there is no need to allocate particular resourcesbefore setting up the flow). In both PQoS multicasting and non-PQoSmulticasting, the Network Controller (NC) assigns a MoCA MulticastChannel ID to the multicast group, so that there is a one-to-one mappingbetween the “Multicast_MAC_DA” (i.e., the destination addresses for thenodes that belong to the multicast group) and the MoCA Multicast ChannelID assigned to a given multicast group. The MoCA Multicast Channel ID isused in both Reservation Requests (RR) and Media Access Plans (MAPs) sothat a receiver can use it to prepare for packet reception.

During the PQoS Create Flow transaction, nodes that do not belong to theMulticast Channel ID will report that they are not involved in the flowby sending back over the network a “RESPONSE_CODE” value equal to“RESPONSE_CODE_UNINVOLVED”. The RESPONSE_CODE is transmitted by thereceiving node in a “Response L2ME Frame” of the PQoS Create Flowtransaction process. Thus, an uninvolved node will never block thecreation of the PQoS flow. For all multicast traffic (PQoS andnon-PQoS), a receiver that does not belong to a multicast channel willnot receive any such multicast traffic. While this method and theassociated apparatus support true multicasting over a network protocolsuch as MoCA in terms of multicast channel management, in oneembodiment, broadcast bit-loading is used for simplicity.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed method and apparatus, in accordance with one or morevarious embodiments, is described with reference to the followingfigures. The drawings are provided for purposes of illustration only andmerely depict examples of some embodiments of the disclosed method andapparatus. These drawings are provided to facilitate the reader'sunderstanding of the disclosed method and apparatus. They should not beconsidered to limit the breadth, scope, or applicability of the claimedinvention. It should be noted that for clarity and ease of illustrationthese drawings are not necessarily made to scale.

FIG. 1 illustrates the interaction between higher layer and MoCA layerfor multicast management for non-Parameterized QoS traffic.

FIG. 2 is a table showing the format of the Submit L2ME frame.

FIG. 3 is a table showing the format of a Request L2ME Frame.

FIG. 4 is a table showing the format of an L2ME_PAYLOAD for a ResponseL2ME Frame used in a Create/Update Multicast Channel Transactions (Wave0).

FIG. 5 is a List of RESPONSE_CODE values.

FIG. 6 is a table showing the format of an L2ME_PAYLOAD for a RequestL2ME Frame used in a Create and Update Multicast Channel Transaction(Wave 1).

FIG. 7 is a list of acceptable decision values.

FIG. 8 is a table showing the format of an L2ME_PAYLOAD for a SubmitL2ME Frame for a Delete Multicast Channel Transaction.

FIG. 9 is a table showing the format for a Response L2ME Frame used in aDelete Multicast Channel Transaction (Wave 1).

FIG. 10 is a table showing the format of a Response L2ME Frame Formatfor a Delete PQoS Flow Transaction (Wave 2).

FIG. 11 is a table showing the format of an L2ME_PAYLOAD of a SubmitL2ME Frame used in a Query Multicast Channel Transaction.

FIG. 12 is a table showing the format of a Response L2ME Frame formatfor a Query Multicast Channel Transaction (Wave 0), if the MulticastChannel is found.

FIG. 13 is a table showing the format of an L2ME_PAYLOAD Field for aSubmit L2ME Frame used in a Create and Update PQoS Flow Transaction.

FIG. 14 is a block diagram showing the interaction between a higherlayer and a MoCA layer for multicast management for Parameterized QoStraffic.

FIG. 15 is a table showing the format of an L2ME_PAYLOAD for ResponseL2ME Frame for a Create PQoS Flow and Update Flow Transaction (Wave 0).

FIG. 16 is a list of RESPONSE_CODE values.

FIG. 17 is a table showing the format of an L2ME_PAYLOAD of Request L2MEFrame for a Create and Update PQoS Flow Transaction (Wave 1).

FIG. 18 is a list of acceptable decision values.

FIG. 19 is a list of Non-bandwidth-related RESPONSE CODEs andcorresponding DECISION values.

FIG. 20 is a table showing the format of an L2ME_PAYLOAD of a SubmitL2ME Frame Format for a Query PQoS Flow Transaction.

FIG. 21 is a table of a Response L2ME Frame format for a Query PQoS FlowTransaction (Wave 0) if the Flow is found.

FIG. 22 is table of the Asynchronous Data/Link Control ReservationRequest Element Format in MOCA 2.0.

FIGS. 23A and 23B are a table of the DAU format.

FIG. 24 is a table of the format of a Request L2ME Frame of Wave 0 ofDelete Multicast Channel Transactions.

The figures are not intended to be exhaustive or to limit the claimedinvention to the precise form disclosed. It should be understood thatthe disclosed method and apparatus can be practiced with modificationand alteration, and that the invention should be limited only by theclaims and the equivalents thereof.

DETAILED DESCRIPTION

A method and apparatus is disclosed to be used in networks thatpreviously have no facility for multicast management.

I. Method 1: Egress Filtering

In one embodiment of the disclosed method and apparatus, forParameterized Quality of Service (PQoS) flows, a broadcast flow iscreated for a multicast flow, using a “PQoS Create Flow” transaction.The Multimedia over Coax Alliance (MoCA) nodes that do not want toreceive this flow respond with a RESPONSE_CODE value of“RESPONSE_CODE_UNINVOLVED” in a “Response Layer-2 Maintenance Entry(L2ME) Frame” of Wave 0 of a Create and Update PQoS Flow Transaction. Anapplication above a MoCA layer of a MoCA node informs the MoCA layer ifit gets involved in a multicast flow. A Multicast PQoS flow isidentified by the FLOW_ID. The FLOW_ID is contained in the a “RequestL2ME Frame” in Wave 0 from a Network Controller (NC) based on an initial“Submit” message.

A MoCA bridge may be pre-configured to get involved in some multicastflows as indicated with FLOW_ID, or is designed to do Internet GroupManagement Protocol (IGMP) snooping to learn dynamically if it getsinvolved in a broadcast PQoS flow.

Each MoCA node will actually receive all MoCA broadcast packets, andegress filtering will drop packets belonging to the multicast groups (asindicated by the destination address, PACKET_DA, of the Ethernet frame)that the MoCA node does not want. Some clarification in the MoCA spec isneeded to clearly allow a node abstain from a broadcast PQoS flowthrough the RESPONSE_CODE value RESPONSE_CODE_UNINVOLVED.

For non-PQoS flows, higher-layer of each node will configure its MoCAreceiver with multicast Media Access Control (MAC) addresses to bereceived, and drop all others.

A major drawback of this method is that some high-layer information(like IGMP entity or provisioning) is needed in order for the MoCA layerto do the egress filtering for multicast traffic, and in order toprevent a low-performance node from blocking the creation of a multicastPQoS flow, a flow that the low-performance node may actually need toreceive.

II. Method 2: Multicast Channel Management over MoCA

This method provides explicit multicast channel management within MoCA,as described below. It will be understood by those skilled in the artthat this method may be used with network architectures other than MoCA,but that MoCA is used as an example.

For Non-Parameterized QoS traffic, the process is defined below. FIG. 1illustrates the interaction between higher layer and MoCA layer formulticast management for non-Parameterized QoS traffic.

The IGMP server initiates the MoCA Multicast Channel Management processby invoking the MoCA Entry node. The MoCA entry node may be the same ordifferent from MoCA multicast ingress node. For each IP multicast, onlyone MoCA multicast channel will be created.

The management protocol used for Multicast Channel Management uses thatsame L2ME protocol used for PQoS transactions. The only difference isthat for non-PQoS multicasting, there is no “TSpec” as that term isdefined by the MoCA 1.0 specification and thus corresponding resourcesinvolved. In both PQoS multicasting and non-PQoS multicasting, theNetwork Controller (NC) assigns a MoCA Multicast Channel ID to themulticast group, so that there is a one-to-one mapping between themulticast media access control destination address (Multicast_MAC_DA)and the multicast channel identification value (Multicast_Channel_ID)for a given multicasting. The Multicast_Channel_ID is used in bothreservation request (RR) and Media Access Plan (MAP) Data AllocationUnit (DAU) so that a receiver can use it to prepare for packetreception.

III. Multicast Channel Management Transactions

a) Multicast Channel Create and Update Transaction

i) Submit L2ME Frame for Multicast Channel Create and Update Transaction

To begin the creation of a multicast channel in the MoCA Network, theEntry Node transmits a Submit L2ME frame to the NC. FIG. 2 is a tableshowing the format of the Submit L2ME frame. The following additionalconstraints are observed on various fields of the Submit L2ME Frame.

  VENDOR_ID = 0x0 (MoCA)   TRANS_TYPE = 0x1 (QoS)   TRANS_SUBTYPE = 0xA(Multicast Channel Create) or 0xB (Multicast Channel Update)  WAVE0_NODEMASK = Set to indicate all L2ME-capable nodes in the MoCANetwork   MSG_PRIORITY = 0xF0   TXN_LAST_WAVE_NUM = 1   L2ME_PAYLOAD =as shown in FIGURE 2

b) Wave 0 of Multicast Channel Create/Update Transactions

i) Request L2ME Frame of Wave 0 of Multicast Channel Create/UpdateTransactions

The NC node initiates Wave 0 using a Request L2ME Frame, the format ofwhich is shown in FIG. 3 and based on the Submit shown in the table ofFIG. 2.

ii) Response L2ME Frame of Wave 0 of Create and Update Multicast ChannelTransactions

In Wave 0, each node responds to the NC node with an L2ME ResponseFrame. The Response L2ME Frame for Multicast Channel Create/UpdateTransaction follows the format shown in FIG. 4. The following additionalconstraints are observed.

RESP_STATUS = Bit 0 set to ‘1’ L2ME_PAYLOAD = as defined in FIGURE 4.Each requested node issues a RESPONSE_CODE where the list of acceptablevalues is shown in FIG. 5. If a node selects multiple RESPONSE_CODEs forrejection of a Create/Update Multicast Channel request, the decisionregarding which RESPONSE_CODE value to include from among all selectedRESPONSE_CODEs in the WAVE 0 L2ME Response message is the numericallyhighest RESPONSE_CODE.

If the ingress node is able to fulfill the NC node request, it issues aResponse Code 0x1 and provide MCAST_CHANNEL_ID.

c) Wave 1 of Create and Update Multicast Channel Transactions

In Wave 1, the NC node informs the nodes about the decision on theMulticast Channel Creation or Update request.

Before the NC node can send the Request L2ME Frame of Wave 1, it needsto determine the outcome of the Create or Update Multicast Channeltransaction and values of other fields of the Request message. Thissection describes how the NC calculates these values and make thedecision to either allow or reject the Create or Update request.

i) Request L2ME Frame of Wave 1 of Create and Update Multicast ChannelTransaction

The NC node sends the Request L2ME Frame for Wave 1. The followingadditional constraints are observed on various fields.

  VENDOR_ID = 0x0 (MoCA)   TRANS_TYPE = 0x1 (QoS)   TRANS_SUBTYPE = OxA(Create Multicast Channel) 0xB (Update Multicast Channel)   WAVE_STATUS= 0   DIR_LEN = 0x00   TXN_WAVE_N = 0x1   L2ME_PAYLOAD = as shown inFIGURE 6.

The DECISION field provides the outcome, as determined by the NC, of theCreate or Update Multicast Channel request from the Entry node. FIG. 7shows meanings for all possible values of this field defined in thisMoCA specification.

If an Update Multicast Channel operation failed, the existing multicastchannel traffic still persists.

From the allowed RESPONSE_CODE values shown in FIG. 5, if the ingressnode or an egress node returns RESPONSE_CODE_TOO_MANY_MCAST_CHANNELS,then the Request L2ME Frame for Wave 1 contains theDECISION_TOO_MANY_MCAST_CHANNELS.

ii) Response L2ME Frame for Wave 1 of Create and Update MulticastChannel Transactions

Upon receiving a Request L2ME Frame indicating a successful Create orUpdate Multicast Channel operation in Wave 1, the ingress and egressnodes for the Multicast Channel commits the requested resources. Eachnode responds with a Response L2ME Frame with format shown in FIG. 4.Following additional restrictions are observed on various fields.

RESP_STATUS: Bit 0 - set to ‘1’ L2ME_PAYLOAD = 32 bit reserved.

d) Wave 2 of Create and Update Multicast Channel Transactions

Wave 2 informs the Entry node and other interested nodes that therequested transaction was completed.

i) Request L2ME Frame of Wave 2 of Create and Update Multicast ChannelTransaction

The NC node initiates Wave 2 using a Request L2ME Frame format using theformat shown in FIG. 4. The following additional restrictions areobserved for various fields.

 VENDOR_ID = 0x0 (MoCA)  TRANS_TYPE = 0x1 (QoS)  TRANS_SUBTYPE = 0xA(Create Multicast Channel Create) 0xB (Update Multicast Update Channel) DIR_LEN = 0x10  TXN_WAVE_N = 0x2  L2ME_PAYLOAD = of type “concatenated”with the concatenated responses from Wave 1.

ii) Response L2ME Frame of Wave 2 of Create and Update Multicast ChannelTransaction

The Create/Update Multicast Channel Transaction is completed when thenodes provide their final Response L2ME Frame using the format shown inFIG. 4. The following additional restrictions are observed on variousfields.

RESP_STATUS = “don't care”. This field is reserved Type II. L2ME_PAYLOAD= 32 bit reserved.

e) Delete Multicast Channel Transaction

i) Submit L2ME Frame for Delete Multicast Channel Transaction

Any node can request to delete any Multicast Channel. The transactionstarts when the Entry node sends a Submit L2ME Frame to the NC node. Thefollowing additional constraints are observed on various fields.

VENDOR_ID = 0x0 (MoCA) TRANS_TYPE = 0x1 (QoS) TRANS_SUBTYPE = 0xC(“Delete Multicast Channel”) WAVE0_NODEMASK = includes all L2ME-capablenodes MSG_PRIORITY = 0xF0 TXN_LAST_WAVE_NUM = 2 L2ME_PAYLOAD = as shownin the table of FIGURE 8.

f) Wave 0 of Delete Multicast Channel Transaction

Wave 0 informs all L2ME-capable nodes of the Multicast Channel to bedeleted.

i) Request L2ME Frame of Wave 0 of Delete Multicast Channel Transaction

The NC node initiates Wave 0 using a Request Frame for which the formatis shown in FIG. 24 based on the Submit L2ME Frame for Delete MulticastChannel Transaction.

ii) Response L2ME Frame of Wave 0 of Delete Multicast ChannelTransaction

Each node responds with a Response L2ME Frame formatted as shown in FIG.4, indicating if it has the resources requested to be deleted. Thefollowing additional constraints are observed on various fields.

  RESP_STATUS: Bit 2 = set to ‘1’ if the node has resources to bedeleted for the requested PQoS Flow   RESP_STATUS: Bit 0 = ‘1’  L2ME_PAYLOAD =32 bit reserved

g) Wave 1 of Delete Multicast Channel Transaction

During Wave 1 the Multicast Channel resources are deleted.

i) Request L2ME Frame of Wave 1 of Delete Multicast Channel Transaction

The NC node initiates Wave 1 using a Request L2ME Frame format with theconcatenated responses from Wave 0.

ii) Response L2ME Frame of Wave 1 of Delete Multicast ChannelTransaction

Each node included in Wave 1 responds with a Response L2ME Frame in Wave1, formatted as shown in FIG. 4. The following additional constraintsare observed.

RESP_STATUS: Bit 0 = ‘1’ L2ME_PAYLOAD = as shown in FIGURE 9.

h) Wave 2 of Delete Multicast Channel Transaction

In Wave 2, the NC node informs the nodes participating in Wave 2 of eachnode's response to the deletion request.

i) Request L2ME Frame of Wave 2 of Delete Multicast Channel Transaction

The NC node initiates Wave 2 using a Request L2ME Frame format with theconcatenated responses from Wave 1.

ii) Response L2ME Frame of Wave 2 of Delete Multicast ChannelTransaction

The Delete Multicast Channel transaction is completed when the Entrynode and any other requested nodes provide their final Response L2MEFrame formatted as shown in FIG. 4. The following additionalrestrictions are observed on various fields

RESP_STATUS = ignored by receiving nodes L2ME_PAYLOAD = as shown intable of FIGURE 10

i) Query Multicast Channel Transaction

The purpose of the Query Multicast Channel Transaction is to retrievethe attributes of a specific Multicast Channel. One usage is to allow aMoCA node to find out the MoCA Channel ID associated to a Multicast MACAddress.

i) Submit L2ME Frame for Query Multicast Channel Transaction

Any node can query any Multicast Channel. The Query Multicast ChannelTransaction starts when the Entry node sends a Submit L2ME Frame to theNC node. The following additional constraints are observed on variousfields.

VENDOR_ID = 0x0 (MoCA) TRANS_TYPE = 0x1 (QoS) TRANS_SUBTYPE = 0xD(“Query Multicast Channel”) WAVE0_NODEMASK = nodes queried MSG_PRIORITY= 0x80 TXN_LAST_WAVE_NUM = 0x1 L2ME_PAYLOAD = as shown in the table ofFIGURE 11.

j) Wave 0 of Query Multicast Channel Transaction

Wave 0 informs the nodes which Multicast Channel is being queried.

i) Request L2ME Frame of Wave 0 of Query Multicast Channel Transaction

The NC node initiates Wave 0 using an L2ME Request Frame format based onthe L2ME Submit message shown in FIG. 11 to the nodes to identify thenodes that hold the specific Multicast Channel.

ii) Response L2ME Frame of Wave 0 of Query Multicast Channel Transaction

Every node which is included in WAVE0_NODEMASK responds with a ResponseL2ME Frame. The following additional restrictions are observed onvarious fields.

RESP_STATUS: Bit 0 = ‘1’ L2ME_PAYLOAD = if node is the ingress node forthe Multicast Channel, essentially as shown in FIGURE 4, and otherwisezero length payload.

k) Wave 1 of Query Multicast Channel Transaction

In Wave 1, the query results are transmitted to the Entry node and othernodes interested in the results.

i) Request L2ME Frame of Wave 1 of Query Multicast Channel Transaction

The NC node initiates Wave 1 using a Request L2ME Frame format with theconcatenated Response L2ME Frames from Wave 0.

ii) Response L2ME Frame of Wave 1 of Query Multicast Channel Transaction

The Query Multicast Channel transaction is completed when the interestednodes send their final Response L2ME Frame. The following additionalrestrictions are observed on various fields.

RESP_STATUS = ignored by receiving nodes L2ME_PAYLOAD = reserved

l) Multicast PQoS Flow Transactions

For Parameterized QoS multicast flows, the process is identical to MoCA1.1 PQoS transactions, except that:

-   1. in Wave 0 of the PQoS Create/Update Flow Transaction, the L2ME    Request frame contains a new field “Multicast_Channel_ID” which is    the Multicast Channel ID assigned by the NC;-   2. Decision_codes related to the Multicast_Channel_ID for each node.

FIG. 14 is a block diagram showing the interaction between a higherlayer and a MoCA layer for multicast management for Parameterized QoStraffic. In all PQoS flow transactions, the EGRESS_NODE_ID field in thepayload are changed into the following:

EGRESS_NODE_ID 8 bits Node ID of the egress node of a Point-to-PointPQoS Flow; 0x3F for a Broadcast PQoS Flow; Reserved for Create PQoSFlow, otherwise the Multicast Channel ID for multicast PQoS flow

During the PQoS Flow Create transaction, nodes that do not belong to theMulticast Channel ID will reports that they are not involved in theflow, thus will never block the creation of the PQoS flow.

m) Create and Update Multicast PQoS Flow Transactions

i) Submit L2ME Frame for Create and Update Multicast PQoS FlowTransaction

To begin the creation or update of a Multicast PQoS Flow in the MoCANetwork, the Entry Node transmits a Submit L2ME frame (format shown inFIG. 24) to the NC. The following additional constraints are observed onvarious field of the Submit L2ME Frame.

 VENDOR_ID = 0x0 (MoCA)  TRANS_TYPE = 0x1 (QoS)  TRANS_SUBTYPE = 0x1(Create PQoS Flow) 0x2 (Update PQoS Flow) (including Multicast now) WAVE0_NODEMASK = Set to indicate all L2ME-capable nodes in the MoCANetwork  MSG_PRIORITY = 0xF0  TXN_LAST_WAVE_NUM = 2  L2ME_PAYLOAD = asshown in FIGURE 13

Note that at the PQoS flow create time, the Entry node differentiates amulticast PQoS flow from the unicast and broadcast PQoS flow by thesetting the field EGRESS_NODE_ID to 0x00. FLOW_TAG1 MAY be used in theRR by the transmitter and by the nodes involved in the PQoS flow(including the transmitter, the receiver and the NC) to doper-flow-based management. Between one MoCA ingress node and one MoCAegress node, there can be more than one unicast PQoS flows using unicastPacket_DA. The use of FLOW_TAG1 allows distinguishing these flows.

n) Wave 0 of Create and Update PQoS Flow Transactions

i) Request L2ME Frame of Wave 0 of Create and Update PQoS FlowTransactions

The NC node initiates Wave 0 using a Request L2ME Frame with the formatshown in FIG. 24 and based on the Submit shown in the table of FIG. 3.

ii) Response L2ME Frame of Wave 0 of Create and Update PQoS FlowTransactions

FIG. 15 is a table showing the format of an L2ME_PAYLOAD for ResponseL2ME Frame for a Create PQoS Flow and Update Flow Transaction (Wave 0).

FIG. 16 is a list of RESPONSE_CODE values.

o) Wave 1 of Create and Update PQoS Flow Transactions

i) Request L2ME Frame of Wave 1 of Create and Update PQoS FlowTransaction

 VENDOR_ID = 0x0 (MoCA)  TRANS_TYPE = 0x1 (QoS)  TRANS_SUBTYPE = 0x1(Create PQoS Flow) 0x2 (Update PQoS Flow) (including Multicast now) WAVE_STATUS = 0  DIR_LEN = 0x00  TXN_WAVE_N = 0x1  L2ME_PAYLOAD = asshown in FIGURE 17.

From the allowed RESPONSE_CODE values shown in FIG. 16, if any nodereturns one of the RESPONSE_CODEs listed in the first column of FIG. 19,then the Request L2ME Frame for Wave 1 contains the correspondingDECISION shown in FIG. 18. If nodes return more than one RESPONSE_CODEvalues shown in FIG. 16, then the NC may choose a DECISION value shownin FIG. 19 corresponding to any of the returned RESPONSE_CODE values.

ii) Response L2ME Frame for Wave 1 of Create and Update PQoS FlowTransactions

p) Wave 2 of Create and Update PQoS Flow Transactions

i) Request L2ME Frame of Wave 2 of Create and Update PQoS FlowTransaction

q) Query PQoS Flow Transaction (including multicast PQoS flow)

The purpose of the PQoS Query PQoS Flow Transaction is to retrieve theattributes of a specific Flow ID.

i) Submit L2ME Frame for Query PQoS Flow Transaction

Any node can query any PQoS Flow. The Query PQoS Flow Transaction startswhen the Entry node sends a Submit L2ME Frame to the NC node. Thefollowing additional constraints are observed on various fields.

VENDOR_ID = 0x0 (MoCA) TRANS_TYPE = 0x1 (QoS) TRANS_SUBTYPE = 0x5(“Query PQoS Flow”) WAVE0_NODEMASK = nodes queried MSG_PRIORITY = 0x80TXN_LAST_WAVE_NUM = 0x1 L2ME_PAYLOAD = as shown in FIGURE 20

r) Wave 0 of Query PQoS Flow Transaction

Wave 0 informs the nodes which PQoS Flow is being queried.

i) Request L2ME Frame of Wave 0 of Query PQoS Flow Transaction

The NC node initiates Wave 0 using an L2ME Request Frame format based onthe L2ME Submit message shown in FIG. 20 to the nodes to identify thenodes that hold the specific PQoS Flow.

ii) Response L2ME Frame of Wave 0 of Query PQoS Flow Transaction

Every node which is included in WAVED_NODEMASK responds with a ResponseL2ME Frame. The following additional restrictions are observed onvarious fields.

RESP_STATUS: Bit 0 = ‘1’ L2ME_PAYLOAD = if node is the ingress node forthe PQoS Flow, as shown in FIGURE 21, otherwise zero length payload.

s) Wave 1 of Query PQoS Flow Transaction

In Wave 1, the query results are transmitted to the Entry node and othernodes interested in the results.

i) Request L2ME Frame of Wave 1 of Query PQoS Flow Transaction

The NC node initiates Wave 1 using a Request L2ME Frame format with theconcatenated Response L2ME Frames from Wave 0.

ii) Response L2ME Frame of Wave 1 of Query PQoS Flow Transaction

The Query PQoS Flow transaction is completed when the interested nodessend their final Response L2ME Frame. The following additionalrestrictions are observed on various fields.

RESP_STATUS = ignored by receiving nodes L2ME_PAYLOAD = RESERVED

t) Multicast Membership and PQoS Flow Create and Update

Due to the dynamic nature of multicast membership, the MoCA egress nodesof a multicast flow may change over time. The high layer of the MoCAingress node will starts the PQoS Flow Create transaction for amulticast flow, if there is at least one receiver for this channel (asdetermined through IGMP). A PQoS Flow Create transaction may succeed orfail depending on the current egress nodes of the multicast flow. Aftera multicast flow has been created and running, if another node hasjoined the multicast group at high-layer through protocols like IGMP,the MoCA ingress node needs to invoke the PQoS Flow Update transactionso that MoCA layer resources are also set up for this new receiver.Update Flow transaction still uses the same EGRESS NODE ID which is theMulticast Channel ID as in the initial Create Flow transaction, with thedifference being that the Multicast Channel ID has a new member (a newegress node), besides the existing members.

All multicast traffic is sent using broadcast bitloading. This is tosimplify the bitloading calculation and probing involved, and thestorage needed.

u) Multicast Membership and Non-PQoS Multicast traffic

For non-PQoS (i.e. prioritized) multicast traffic, IGMP protocol entityon a MoCA receiver will instruct the MoCA layer to receive only thetraffic of multicast channels to which the receiver belong, and ignoreall others. This pre-filtering is possible because the multicast channelIDs are carried in the DAU of the MAP.

Conclusion

In Method 2, during the PQoS Flow Create transaction, nodes that do notbelong to the Multicast Channel ID will reports that they are notinvolved in the flow, thus will never block the creation of the PQoSflow. For all multicast traffic (PQoS and non-PQoS), a receiver thatdoes not belong to a multicast channel will not receive them.

Method 2 needs some spec changes in the MoCA 2.0 spec, and supports truemulticasting over MoCA in terms of multicast channel management,although broadcasting bit-loading is used for simplicity.

IV. Reservation Request Element Format

FIG. 22 is a table of the Asynchronous Data/Link Control ReservationRequest Element Format in MOCA 2.0.

V. MAP Data Allocation Unit Format (DAU)

The MAP DAU indicates a multicast transmission of an Ethernet packet byspecifying the following parameters:

✓ FRAME_TYPE = Ethernet transmission ✓ FRAME_SUBTYPE = priority of thepacket ✓ DESTINATION = Multicast Channel ID for multicast ✓ PHY_PROFILE= 0x13 (multicast profile) ✓ FLOW_TAG1 = unique identifier for a PQoSflow from a given ingress node

FIGS. 23A and 23B are a table of the DAU format. Note that because the8-bit field of DESTINATION is used to define both the Node ID of thedestination node (unicast or broadcast), and the Multicast channel ID(multicast), a specific value of PHY_PROFILE is used to differentiate amulticast transmission from a unicast transmission and a broadcasttransmission. In this spec, the multicast profile uses the broadcastbitloading for simplicity.

VI. Co-existence between the Managed Multicasting and LegacyMulticasting

The multicasting management protocol described in this spec assumes thatsome higher-layer entity like IGMP server/Proxy invokes the MoCA layer.For a given MoCA node, its applications may send multicast packets toits ECL without first or ever invoking the MoCA multicasting managementprocess. The transmitter will transmit these packets as broadcastpackets as in MoCA 1.x. This legacy multicasting and the managedmulticasting, as described in this spec, can coexist without anycompatibility issue.

While various embodiments of the disclosed method and apparatus havebeen described above, it should be understood that they have beenpresented by way of example only, and should not limit the claimedinvention. Likewise, the various diagrams may depict an examplearchitectural or other configuration for the disclosed method andapparatus. This is done to aid in understanding the features andfunctionality that can be included in the disclosed method andapparatus. The claimed invention is not restricted to the illustratedexample architectures or configurations, rather the desired features canbe implemented using a variety of alternative architectures andconfigurations. Indeed, it will be apparent to one of skill in the arthow alternative functional, logical or physical partitioning andconfigurations can be implemented to implement the desired features ofthe disclosed method and apparatus. Also, a multitude of differentconstituent module names other than those depicted herein can be appliedto the various partitions. Additionally, with regard to flow diagrams,operational descriptions and method claims, the order in which the stepsare presented herein do not mandate that various embodiments beimplemented to perform the recited functionality in the same orderunless the context dictates otherwise.

Although the disclosed method and apparatus is described above in termsof various exemplary embodiments and implementations, it should beunderstood that the various features, aspects and functionalitydescribed in one or more of the individual embodiments are not limitedin their applicability to the particular embodiment with which they aredescribed. Thus, the breadth and scope of the claimed invention shouldnot be limited by any of the above-described exemplary embodiments.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; the terms “a” or“an” should be read as meaning “at least one,” “one or more” or thelike; and adjectives such as “conventional,” “traditional,” “normal,”“standard,” “known” and terms of similar meaning should not be construedas limiting the item described to a given time period or to an itemavailable as of a given time, but instead should be read to encompassconventional, traditional, normal, or standard technologies that may beavailable or known now or at any time in the future. Likewise, wherethis document refers to technologies that would be apparent or known toone of ordinary skill in the art, such technologies encompass thoseapparent or known to the skilled artisan now or at any time in thefuture.

A group of items linked with the conjunction “and” should not be read asrequiring that each and every one of those items be present in thegrouping, but rather should be read as “and/or” unless expressly statedotherwise. Similarly, a group of items linked with the conjunction “or”should not be read as requiring mutual exclusivity among that group, butrather should also be read as “and/or” unless expressly statedotherwise. Furthermore, although items, elements or components of thedisclosed method and apparatus may be described or claimed in thesingular, the plural is contemplated to be within the scope thereofunless limitation to the singular is explicitly stated.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instances arenot meant to be read to imply that the narrower case is intended orrequired in instances where such broadening phrases may be absent. Theuse of the term “module” does not imply that the components orfunctionality described or claimed as part of the module are allconfigured in a common package. Indeed, any or all of the variouscomponents of a module, whether control logic or other components, canbe combined in a single package or separately maintained and can furtherbe distributed in multiple groupings or packages or across multiplelocations.

Additionally, the various embodiments set forth herein are described interms of exemplary block diagrams, flow charts and other illustrations.As will become apparent to one of ordinary skill in the art afterreading this document, the illustrated embodiments and their variousalternatives can be implemented without confinement to the illustratedexamples. For example, block diagrams and their accompanying descriptionshould not be construed as mandating a particular architecture orconfiguration.

What is claimed is:
 1. A method for performing multicast channelmanagement within a network communication protocol, comprising:identifying a first subset of a plurality of network nodes to which amulticast communication is to be directed; assigning a multicast channelID to a multicast group to generate a one-to-one mapping between themulticast channel ID and destination addresses for the nodes that belongto the multicast group; and sending a broadcast communication to allnetwork nodes in a broadcast flow, wherein said first subset of networknodes can determine from said multicast channel ID whether to receivesaid broadcast flow, wherein a second subset of said plurality ofnetwork nodes that does not want to receive said multicast trafficmessage perform the steps comprising: recognizing a multicast channel IDas belonging to a multicast communication that said second subset ofnetwork nodes does not wish to receive, and filtering out said multicastcommunication from said broadcast flow.
 2. The method of claim 1,wherein said filtering is performed by egress filtering.
 3. The methodof claim 1, wherein said recognizing a multicast channel ID as belongingto a multicast communication that said second subset of network nodesdoes not wish to receive comprises: configuring said second subset ofnetwork nodes to receive packets for non-PQoS flows; and rejecting allother flows.
 4. A computer program product, comprising a non-transitorymedium having a computer readable program code embodied therein, saidcomputer readable program code performing a method for managing amulticast communication among a plurality of network nodes when executedby a computer, said network nodes being arranged in a Multimedia overCoax Alliance (MoCA) protocol layer and a higher protocol layer, saidmethod comprising: informing the MoCA layer, from the higher protocollayer, whether a receiving node in which the computer readable programis being executed will get involved in the multicast communication basedon a MoCA address associated with the multicast communication; sendingall broadcast packets to each network node of the plurality of networknodes; filtering out broadcast packets belonging to a multicast group towhich the receiving node does not wish to belong at the MoCA layer. 5.The computer program product of claim 4, wherein said sending allbroadcast packets to each network node comprises sending parameterizedquality of service (PQoS) communications.
 6. The computer programproduct of claim 4, wherein said sending all broadcast packets to eachnetwork node comprises sending non-parameterized quality of service(non-PQoS) communications.
 7. The computer program product of claim 6,further comprising configuring a receiver of each network node withmulticast media access control (MAC) destination addresses, wherein ifany communication is received that is are directed to one of the MACdestination addresses, that communication will be received, and allother communications will be dropped at the MoCA layer.